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PARAMETERIZED LOCK MANAGEMENT 
SYSTEM AND METHOD FOR 
CONDITIONAL CONFLICT 
SERIALIZABILTTY OF TRANSACTIONS 

The present invention relates generally to database man- 
agement systems and transaction processing systems that 
utilize a lock manager for protecting database resources 
from simultaneous incompatible uses, and more particularly 
to a lock manager that allows greater concurrent use of 
resources than the lock managers in traditional transaction 
processing systems while diminishing the "ACID" proper- 
ties of transactions only with respect to isolation between 
concurrent transactions. 

BACKGROUND OF THE INVENTION 

The present invention is directed at the management of 
transactions in database management systems so as to enable 
greater concurrency, and therefore more efficient transaction 
execution, than is allowed by DBMS's requiring strict 
adherence to the traditional "ACID" properties of transac- 
tions. More specifically, the present invention is directed at 
solving the "serializability" problems introduced by long 
lived transactions (LLT's). In addition to DBMS's and 
transaction processing monitors, the present invention may 
also be used in persistent programming languages as well as 
to concurrency control services for object resource broker- 
age systems. For simplicity, the present invention will be 
described with respect to DBMS's. 

The idea of revising or redefining the ACID properties of 
transactions to enable more efficient execution of transac- 
tions in systems that support LLT's is not new. However, the 
present invention provides a new methodology of "param- 
eterized lock management" that is relatively simple to 
implement and that allows applications to explicitly control 
the degree to which they can tolerate diminished isolation 
between concurrent transactions. 

THE TRADITIONAL TRANSACTION ACID 
PROPERTIES 

Traditional database management systems (DBMS's) 
were developed to support short, atomic transactions, such 
as for banking and airline reservation applications. Standard 
transaction management uses flat transactions that adhere to 
the ACID properties. ACID stands for Atomicity, 
Consistency, Isolation and Durability. 

Atomicity means that either the results of the transaction 
(i.e., changes to the database) are all properly reflected in the 
database, or none of them are. Generally, a transaction is said 
to commit or abort. When a transaction commits, all changes 
made to the database by the transaction are durably stored, 
leaving the database in a consistent state. When a transaction 
aborts, any changes made to the database by the transaction 
are backed out, once again leaving the database in a con- 
sistent state. 

Consistency means that each transaction commits only 
legal results to the database. Thus, a transaction must bring 
the database from one consistent state to another consistent 
state. 

Isolation means that the events within a transaction must 
be hidden from other transactions running concurrently. 
Concurrent transactions must not interfere with each other. 
They execute as if they had the database to themselves. 

Durability means that once a transaction has been com- 
pleted and has committed its results to the database, the 



system must guarantee that these results survive any subse- 
quent malfunctions. 

The concept of atomicity for transactions is sometimes 
overloaded with additional meaning. In particular, some- 

5 times atomicity is defined to mean "concurrency atomicity," 
meaning that no transaction can observe any partial results 
of an atomic transaction. This document and the present 
invention, however, take the opposite approach. In 
particular, in this document atomicity is defined to mean that 

10 a transaction's commitment must be atomic. That is, once 
some work is committed to the DBMS (as opposed to 
committed to the parent of a sub transaction), the transaction 
in question cannot continue to perform work that may or 
may not be committed at some later point in time. This 

15 notion of atomicity excludes such things as open nested 
transactions, but does not exclude partial rollbacks, the use 
of persistent savepoints, or other mechanisms that can be 
used by application programmers to control the behavior of 
the system's recovery mechanisms, since the final outcome 

20 of the transaction is still abort or commit. 

Failure atomicity implies that all effects of incomplete 
transactions must be undone in the case of failure. Failure 
atomicity may be undesirable for long lasting transactions 
(LLT's). For example, a designer who experiences a power 

25 failure just as he is about to commit a week's worth of work 
is unlikely to consider failure atomicity to be a valuable 
property of the design database. The obvious solution for 
this situation (as well as many other LLT's) is for LLT's to 
have persistent savepoints, which would make it possible to 

30 recover an incomplete transaction to the last savepoint taken 
before a crash. It is noted that removing failure atomicity 
does not require removing commitment atomicity. 

The atomicity and durability properties of transactions are 
required for system failure recovery, the isolation property is 

35 required for concurrency control, and the consistency prop- 
erty is needed for both failure recovery and concurrency 
control. 

It is well known that the ACID properties are well suited 
4Q for virtually all kinds of short duration transactions. LLT's 
seem to be the only class of transactions where the ACID 
properties cause significant problems. LLT's can be complex 
queries that last for minutes or hours, data mining queries 
that last for hours or days, or concurrent engineering 
45 transactions, controlled by humans and lasting from minutes 
to months. Full application of the ACID properties in a 
DBMS that supports LLT's can effectively prevent multiple 
users from simultaneously using the system. Long term 
locking of system resources by an LLT can prevent other 
5Q users or transactions from being able to perform useful 
work. 

It is a premise of the present invention that three of the 
ACID properties remain highly desirable for LLT's: 

Keeping commitment atomicity for LLT's is universally 
55 acknowledged as being desirable. Just like short dura- 

tion transactions, LLT's should have only two possible 
outcomes: commit all work or abort all work (but see 
comments above regarding failure atomicity). 
Therefore, retaining commitment atomicity is desir- 
60 able- 
Inconsistencies in a database are undesirable, although 
some kinds of inconsistencies may have to be tolerated 
when dealing with LLPs. Maintaining consistency is 
desirable, even for LLT's. 
65 Whether or not a transaction lasts a long time before it 
commits, durability for a committed transaction is 
always desirable. 
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It is a premise of the present invention that isolation is the 
only ACID property that it is desirable to compromise so as 
to reduce the impact of LLT's on system performance. More 
specifically, it would be desirable to compromise isolation in 
a controlled manner so as to give rise to as little inconsis- 
tency in the database as possible. 

It is a primary object of the present invention to provide 
a lock manager mechanism for providing applications the 
ability to explicitly control the extent to which concurrent 
transactions are isolated from each other or share data with 
each other. 

SUMMARY OF THE INVENTION 

In summary, the present invention is a database manage- 
ment system (DBMS) that has been modified to provide 
improved concurrent usage of database objects, particularly 
when the system is executing long lived transactions. A 
subset of the transactions access database objects using 
parameterized read and parameterized write access modes. 
Each transaction using a parameterized write mode of access 
for a database object specifies a write access mode and a 
write access mode parameter, where the write access mode 
parameter indicates a reliability classification that indicates 
the reliability of the write locked data. Each transaction 
using a parameterized read mode of access for a database 
object specifies a read access mode, and a read access mode 
parameter, where the read access mode parameter indicates 
one or more reliability classifications that are acceptable to 
the transaction. Whenever a transaction requests access to a 
database object, the DBMS generates a corresponding lock 
request for the object. If the access request is a parameter- 
ized conditional access request, a corresponding parameter- 
ized lock request is generated. 

A lock manager processes each lock request by checking 
to see if any previously granted lock is conflicting or 
potentially conflicting with the requested lock. Two lock 
requests are unconditionally conflicting if their resource 
range overlaps and the access modes of the two requests are 
incompatible. Two requests are conditionally conflicting if 
analysis of their read/write parameters is necessary to deter- 
mine whether a conflict exists. If the lock request being 
processed is unconditionally conflicting with any 
outstanding, previously granted lock, the lock request is put 
on a queue of pending requests. If the lock request is not 
unconditionally conflicting with any outstanding, previously 
granted locks, but is conditionally conflicting with an 
outstanding, previously granted lock, the conditional con- 
flict is resolved by determining whether the write parameters 
for the write lock in question are a subset of the read 
parameters for the read lock in question. If so, then there is 
no conflict. If not, then the requested lock is in conflict with 
the outstanding previously granted lock. In none of the 
outstanding, previously granted locks is in conflict with the 
requested lock, the requested lock is granted. Otherwise it is 
put on a queue of pending lock requests. 

Every time a previously granted lock is released, any 
pending lock requests that overlap with the resource asso- 
ciated with the released lock are reevaluated. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Additional objects and features of the invention will be 
more readily apparent from the following detailed descrip- 
tion and appended claims when taken in conjunction with 
the drawings, in which: 

FIG. 1 is a block diagram of a database management 
system implementing the present invention. 
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FIG. 2 depicts a set of lock management data structures 
for keeping track of granted and pending resource lock 
requests. 

FIG. 3 depicts an alternate set of lock management data 
5 structures for keeping track of granted and pending resource 
lock requests. 

FIG. 4 is a flow chart of the object locking method of the 
present invention. 

10 DESCRIPTION OF THE PREFERRED 

EMBODIMENTS 

Referring to FIG. 1, there is shown a database manage- 
ment system (DBMS) 100. Transaction operation and man- 

15 agement are handled by a transaction manager 102 and a 
lock manager 104, both of which are software procedures 
executed by the system's data processors) 106. The trans- 
action manager maintains a transaction table 108, sometimes 
implemented as a tree structure, for keeping track of the 

20 identity and status of all pending transactions. The lock 
manager 104 maintains a lock table 110, usually imple- 
mented using a hash table and various linked lists and/or tree 
structures (which will be discussed in more detail below). 
The lock table 110 keeps track of all locks that have been 

25 requested on resources in a database 112. The database 112 
stores all of the data that is accessible to transactions 
executed by the DBMS 100. 

The DBMS 100 will typically also include additional 
memory resources 114, one or more system busses 116 for 

30 interconnecting the various parts of the system, and a 
network interface 118 or other communications interface for 
handling communications with client workstations 120. 

"Conflicting transactions" are two or more transactions 
that access the same resource and at least one of them will, 

35 at least potentially, update the resource in question. Thus the 
results generated by at least one of the conflicting transac- 
tions may depend on the order in which the transactions are 
performed. 

A "data lock" is a mechanism for assigning a transaction 

40 certain rights to a database object, such as a table, a page, or 
a datum or record in a database table. Thus a first transaction 
may lock a particular object so as to ensure that no other 
transaction accesses the data in that data until the first 
transaction commits or aborts. The prior art includes many 

45 types of data locking mechanisms. 

"Overlapping resources" are database objects whose 
address range is the same or at least partially overlapping. 
An "access mode" refers to the way in which a transaction 

50 or application accesses a data resource. The traditional 
access modes (browse, read, update, write and exclusive) are 
described below. When using the parameterized read and 
write access modes of the present invention, each unique 
read access parameter value is associated with a distinct read 

55 access mode, and each unique write access parameter value 
is associated with a distinct write access mode. 

Lock Table Data Structures Supporting 
Parameterized Resource Access Requests and 
Access Modes 

60 

Referring to FIG. 2, the "lock table" 110 in a preferred 
embodiment is implemented as follows. A hash function 150 
is used to convert a resource identifier into a hash table 
address in a fixed size hash table 152. The resource identifier 
65 that is hashed by function 150 may include a resource type 
or level indicator (e.g., indicating whether the resource to be 
locked is a database, table, page or tuple) and the starting 
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address of the resource. Each addressable slot 154 of the 
hash table includes either a null value if there are no locked 
resources corresponding to that slot's hash table address, or 
a pointer to a list of lock control blocks (LCB's) 160 if there 
is at least one locked resource whose hash value corresponds 5 
to that slot's hash table address. 

The lock manager will allocate (i.e., generate and store) 
one lock control block (LCB) 160 for each lockable data 
item that is actually locked, and will allocate (i.e., generate 
and store) one lock request block (LRB) 162 for each lock 10 
held by a transaction. Thus, if a particular database object is 
locked by three different transactions at a given point in 
time, there will be one LCB 160 for that object and a linked 
list of three LRB's (one per transaction) "hanging" from that 
LCB. 15 

Each LCB 160 preferably includes: 

a lock ID 170, which will typically include a copy of the 
resource identifier for a locked resource; 

a mode indicator 171 indicating the most restrictive 2 o 
access mode (e.g., browse, read, parameterized read, 
write, parameterized write, or exclusive) of all the locks 
granted on the database resource represented by this 
LCB; 

a read parameters indicator 172, preferably in the form of 25 
a bitmap, representing the logical OR of the read 
parameters being used by the parameterized read locks 
(if any) outstanding on the locked resource; 
a write parameters indicator 173, preferably in the form of 
a bitmap, representing the write parameters of the 30 
parameterized write lock (if any) outstanding on the 
locked resource; 
a granted request list pointer 174 to a list of LRB's 162 for 
granted (i.e., currently outstanding) resource requests 
for the database resource represented by this LCB; 35 
a pending request list pointer 175 to a list (also called a 
queue) of LRB's 162 for pending (i.e., not yet granted) 
resource requests represented by this LCB; and 
a next LCB pointer 176 to the next LCB (if any) sharing ^ 

the same hash address as this LCB. 
The read and write parameters represented by fields 172 
and 173 in LCB 160 represent an extension by the present 
invention to the conventional access modes used by 
DBMS' s, and are discussed in more detail below. Each 45 
distinct value of a defined set of read/write parameter 
domain represents a corresponding data reliability classifi- 
cation or category. Thus a parameter domain having eight 
parameter values (each represented by a corresponding bit of 
an eight-bit parameter field) would allow for the definition 50 
of up to eight different data reliability classifications. In 
other embodiments of the present invention the parameters 
may be used to indicate properties of a database object other 
than " re li ability," such as the type or identity of the appli- 
cation which holds a write lock on the object, or other 55 
information that can be used by applications to determine if 
they are willing to read the data despite the presence of a 
write lock on it. 

Each LRB 162, representing one granted or pending lock 
request, preferably includes: 60 
a mode indicator 181, indicating the access mode (e.g., 
browse, read, parameterized read, write, parameterized 
write, or exclusive) in which the resource is being 
accessed or being requested by a particular transaction; 
a transaction identifier 184, which identifies the tr ansae- 65 
tion that requested or holds the lock corresponding to 
this LRB; 
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a parameters indicator 182, preferably in the form of a bit 
map, representing the read or write access mode param- 
eters (if any) being used by the owner of this read or 
write lock; this field is used only if the owner of this 
lock or lock requested is using a parameterized access 
request; 

a lockset pointer 185 that is used to form a linked list of 
all the LRB's owned by transaction identified by the 
transaction ID 184; and 
a Next LRB pointer 186 to the next LRB (if any) for the 

same database resource as this LRB. 
Typical sizes for the read and write parameter fields in the 
LCB's and the access mode parameter field in the LRB's are 
one to two bytes, supporting eight to sixteen distinct param- 
eter values. 

FIG. 3 depicts an alternate data structure implementation 
110' of the lock table. In this implementation, the lock 
control blocks (LCB's) 190 each contains a granted request 
bitmap 194 and a pending request bitmap 195 in place of the 
granted and pending request list headers 174 and 175. Each 
of the request bitmaps preferably contains a bitmap of 
sufficient size (e.g., 64 or 128 bits) to represent the maxi- 
mum number of concurrent transactions supported by the 
system. Every active transaction is assigned to one of the 
bitmapped transaction identifiers. The granted request bit- 
map 194 contains a set bit for each active transaction that has 
been granted a lock on the resource represented by the LCB 
190. Similarly, the pending request bitmap 195 contains a set 
bit for each active transaction that has a pending lock request 
(also called an access request) on the resource represented 
by the LCB 190. 

The read and write parameter bitmaps 172 and 173, as in 
the FIG. 2 implementation, represent all the read and write 
parameterized access modes that have been granted on the 
database resource represented by the LCB 190. 

Whenever a lock request is granted, the read and write 
parameters in the LCB in question are efficiently updated by 
logically ANDing the read/write parameters of the granted 
lock request with the read/write parameter bitmaps previ- 
ously stored in the LCB. Ideally, when a lock is released, one 
would like the read and write parameters in the correspond- 
ing LCB to be immediately updated. However, this would 
require ORing the read parameters of all remaining read lock 
holders (if a read lock is released) and ORing the write 
parameters of all remaining write lock holders (if a write 
lock is release). Since this would put an undue delay on 
transaction commit processing, in a preferred embodiment 
the lock is released without updating the read and write 
parameter bitmaps in the LCB. If there are no more lock 
holders for the resource in question, the read and write 
parameter bit maps can be cleared, and if there are no 
pending lock requests, then the LCB can be eliminated 
altogether. Otherwise, the read and write parameter bitmaps 
in the LCB are updated with respect to lock releases only 
when a potential read/write or write/read conflict is detected, 
in order to figure out whether to grant the requested lock. 
Alternately, LCB read/write parameter bitmap updating can 
be handled as a background task, similar to garbage collec- 
tion. 

Serializable Transaction Histories 

A transaction history is defined to be serializable if it is 
equivalent to a serial transaction history. This definition only 
makes sense if we also define what it means for two histories 
to be equivalent and what it means for a history to be serial. 
Equivalence can be defined in more than one way. Two 
histories are "conflict equivalent" if: 
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they contain the same transactions and the same opera- 
tions; and 

conflicting operations of non-aborted transactions are 
ordered the same way in both histories. 

Two operations are defined to conflict if they do not 
commute. That is, if the results of executing one before the 
other is in general not equivalent to executing them in the 
reverse order. It is common to model transactions as con- 
sisting of read and write operations only, and the conflict 
relation for those two operations is that two operations 
conflict if at least one of them is a write operation. The basic 
lock compatibility matrix is: 
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where "*'* in Table 1 (as well as in the following tables) 
indicates no n -conflicting operations. Table 1 indicates that 
two transactions can read the same data item, but a trans- 
action that is performing write operations must have exclu- 
sive access to it. 

A transaction history H is serial if for every pair of 
transactions T f and T,-, either all operations of T, come before 
all operations of T f in H, or all operations of T y - come before 
all operations of T f - in H. In other words, a transaction history 
is serial if it does not have any concurrency. Each transaction 
executes to completion before the next one starts. If trans- 
actions are atomic, durable and consistent, then a serial 
transaction history will be correct. It follows that a concur- 
rent execution of transactions that is conflict equivalent to a 
serial one, must necessarily be correct, too. A transaction 
history that is conflict equivalent to a serial history is called 
conflict serializable, and the corresponding correctness cri- 
terion is called conflict serializability. 

A serialization graph (SG) for a transaction history H is 
denoted SG(H). This is a directed graph whose nodes are the 
committed transactions of H, and it has an edge between all 
pairs of nodes representing transactions that have issued 
conflicting operations. The direction of the edges are in 
accordance with the sequence of the conflicting operations. 
An edge from T t - to T y in SG(H) means that T,- as issued an 
operation that conflicts with and precedes some operation 
issued by T y -. Intuitively, if T ( - and T y - are involved in a cycle 
in SG(H), then T t - comes both before and after T,- in H, in 
which case H cannot be equivalent with any serial history. 
The fundamental theorem of serializability says that a his- 
tory H is serializable if and only if its serialization graph 
SG(H) is acyclic. 

To enforce serializability, virtually all commercial 
DBMS's use some form of data locking. Two phase locking 
(2PL) operates according to the following rules: 

1) a transaction may not perform an operation on a data 
item unless it holds a lock corresponding to the opera- 
tion (e.g., a read or write operation) in question on that 
data item; 

2) a lock request from a transaction must be delayed or 
rejected by the transaction scheduler if another trans- 
action holds a conflicting lock on the data item in 
question; and 

3) a transaction may not acquire a new lock if it has 
released any of its old ones. 

The first two rules prevent transactions from directly 
interfering with each other. The third rule, called the two 
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phase locking rule, prevents cycles in the serialization graph. 
The intuitive explanation of the two phase locking rule is as 
follows. When a transaction acquires a lock, that may 
establish an incoming edge to its node in the serialization 
5 graph. An outgoing edge from a transaction's node in the 
serialization graph can only be established if that transaction 
has released a lock. Thus, in order to create a cycle in the 
serialization graph, some transaction must first release a lock 
and then later acquire a lock. Since this is prohibited by the 
10 two phase locking rule, transaction schedulers that obey the 
two phase locking rule ensure acyclicity of serialization 
graph's, and therefore ensure serializable histories. 

In addition to serializability, it is important for a transac- 
tion management system to maintain a "strict" history by: 
15 avoiding cascading aborts (ACA), in which the failure of 
a first transaction causes other transactions that 
depended on the results computed by the first transac- 
tion to abort; and 
ensuring that all data items written by a transaction T £ 
20 cannot be overwritten by another transaction until after 

transaction T # has aborted or committed. 
The solution for maintaining a strict transaction history is 
to add the restriction that all write locks acquired by a 
transaction must be held until the transaction commits. A 
25 rigorous transaction history is maintained by requiring that 
all read and write locks acquired by a transaction be held 
until the transaction commits. With these added restrictions, 
two phase locking is called "strict two phase locking," or 
strict 2PL. 

30 A nasty problem with transaction schedulers that use the 
two phase locking rule is that transactions can get involved 
in deadlocks. As a consequence of the second locking rule, 
transactions sometimes have to wait for locks. Such waiting 
is caused by another transaction holding a conflicting lock, 

35 and the waiting transaction cannot make any progress until 
the other transaction releases its lock. If two transactions are 
waiting for each other, neither can make progress until the 
other one releases its lock. As long as neither of them 
releases its lock, the two transactions are deadlocked. More 

40 generally, deadlocks can involve more than two transactions 
that are waiting for each other in a cyclic way. 

Transaction Isolation Levels 

While isolation levels (i.e., levels of isolation between 
45 transactions) can be defined without reference to any par- 
ticular implementation technique, the present invention 
assumes the use of a lock manager for implementing isola- 
tion control. Isolation levels supported by commercial 
systems, ordered from least to most restrictive, include: 
50 UR (uncommitted read). This is also known as read 
uncommitted, read through, or dirty read. This isolation 
level allows an application to read both committed and 
uncommitted data. As a result, the data read by an 
application (i.e., transaction) may be inconsistent with 
55 other data read by the application. Applications using 

the UR isolation level do not acquire any ordinary read 
locks, but will typically hold a browse lock at some 
high level in the resource hierarchy. Applications using 
the UR isolation level must still use write locks to 
60 protect write operations. There are two types of situa- 

tions where UR isolation is most typically used: 
(1) when the application does not need an exact answer, 
and (2) when the application (i.e., the person who wrote 
the application) knows that the data to be read is not 
65 being updated by anyone else. 

CR (committed read). This is also known as read com- 
mitted. The committed read isolation level allows an 



application to read only committed data. CR isolation 
can be implemented using "zero duration" read locks. 
That is, if an application wants to read a database 
object, if suffices for the DBMS to check that a read 
lock could have been granted. If the read lock could 
have been granted, the object is read, but a read lock is 
not acquired. CR isolation is much less expensive than 
cursor stability (CS) isolation (described below) in 
terms of CPU cycles. Unless an application needs the 
additional semantics offered by cursor stability isola- 
tion (and many applications do not), committed read 
isolation is the better alternative. 
CS (cursor stability). Cursor stability isolation allows an 
application to read only committed data and guarantees 
that a row will not change as long as a cursor is 
positioned to it. CS isolation causes locks to be kept 
until the cursor moves to the next lockable object. For 
example, CS isolation is useful for an application that 
fetches a row from a database table (using a cursor to 
point to the row) and then performs a database manipu- 
lation based on the current row's data values before 
fetching another row. An application should have at 
least CS isolation for cursors that are to be used to point 
to rows of data that are to be updated or deleted by 
UPDATE or DELETE operations. 
RR (repeatable read). RR isolation allows an application 
to read only committed data and guarantees that read 
data will not change until the transaction terminates 
(i.e., a read that is repeated will return the original row, 
unchanged). RR isolation will not prevent the so-called 
phantom row phenomenon. That is, when a cursor is 
reopened, a row not present the previous time may 
appear. Read locks covering data items retrieved by an 
application using RR isolation must be kept until the 
transaction commits or aborts. 
TC (transaction consistency). TC isolation is also known 
as serializable isolation. TC isolation allows an appli- 
cation to read only committed data and guarantees that 
the transaction has a consistent view of the database, as 
if no other transactions were active. Transactions using 
TC isolation may be part of a transaction history that is 
not serializable where other transactions use lower 
levels of isolation. On the other hand, if all transactions 
in a history use TC isolation, that history will be 
serializable. All read locks acquired by a transaction 
using TC isolation must be kept until the transaction 
commits or aborts. 
Another isolation level is the QC (query consistency) 
level. QC isolation allows an application to read only 
committed data, and guarantees that all data accessed in a 
single query is consistent. Implementing QC isolation by 
means of data locking is straightforward: all read locks must 
be kept until the query is completed (i.e., until the cursor is 
closed). Since cursors are defined using queries, QC isola- 
tion guarantees that all rows in a cursor's answer set are 
consistent. QC isolation is also valuable when performing 
statistical analysis, or when comparing or otherwise using 
together data values from different cursor row occurrences. 
QC isolation is weaker than RR isolation, but stronger than 
CS isolation. 

Isolation level CS, or weaker, is often not suitable for any 
query that uses aggregation and for any application that 
processes a cursor where the answer set must be consistent. 
While using RR or TC isolation solves this problem, RR and 
TC actually provide more isolation than is needed for most 
such applications. The QC isolation level is the lowest 
isolation that provides the necessary and sufficient isolation 
for such queries. 
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Transaction Access Modes 

There are two basic access modes: read and write. When 
a database object is accessed in read mode, the agent in 
question can perform only read operations on that object. 
5 Two or more transactions may access a given object 
concurrently, provided they all use read mode. When a 
database object is accessed in write mode, the transaction in 
question can perform both read and write operations on that 
object. More specifically, write mode enables reading, 
10 deleting, inserting and modifying objects. If an object is 
accessed in write mode by one transaction, no other trans- 
action can access that object in either read or write mode. In 
addition to these two basic access modes, many DBMS' s 
support browse, upgrade and exclusive access modes. 

Browse mode enables a transaction to read an object even 
if some other transaction is currently accessing it in write 
mode. Thus, when using browse mode, transactions have no 
guarantee of a consistent view of the database, since there is 
2Q a risk that they will read uncommitted data. The use of 
browse mode is often denoted as read through mode or dirty 
read mode, and is used with isolation level UR. Even an 
application using the UR isolation level needs to inform 
others of its presence, and it does so by accessing resources 
in browse mode. 

Upgrade mode is similar to read mode, with the added 
semantics that the transaction in question may at any time 
request an upgrade to write mode. That is, it may upgrade its 
access mode. When a first transaction accesses an object in 
30 upgrade mode, no other transaction can access the same 
object in write mode, or upgrade mode, until the first 
transaction commits or aborts. 

Support for upgrade mode was added to DBMS's to 
prevent single object deadlocks. Some applications work as 
35 follows: a number of database objects are "looked at," but 
only some of these are updated or deleted. If all the objects 
in question are "looked at," in write mode, the problem is 
unacceptably low concurrency. The alternative, assuming 
upgrade mode is not supported, is to "look at" objects in read 
40 mode and then promote from read to write mode whenever 
an update or delete operation is to be performed. The 
problem with this approach is that two transactions may 
access the same object in read mode, and if they both request 
promotion to write mode, the result is deadlock. This 
45 dilemma is eliminated by supporting upgrade mode, since 
upgrade modes are not mutually compatible. 

Exclusive mode is used by a transaction to prohibit any 
other transactions from accessing the same object, irrespec- 
tive of access mode. Exclusive mode is used when even 
so browsers must be denied access to an object, such as when 
a table is to removed from a relational database. 

The relationship between the five traditional access modes 
is represented by Table 2, where B represents browse mode, 
R represents read mode, U represents upgrade mode, W 
55 represents write mode and X represents exclusive mode. 



TABLE 2 
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Asterisks (*) in Table 2 indicate compatibility. For 
example, read mode (R) access by a first transaction is 
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compatible with browse (B), read (R) or upgrade (U) mode 
in a second transaction. Write mode (W) is compatible only 
with browse mode. Exclusive mode (X) is not compatible 
with any other access mode. 

The five access modes are typically implemented using ; 
locks. It should be noted that it is usually necessary to 
support a number of different lock granularities. Typical lock 
granularities are tuple (i.e., database table row), object, page, 
table, class, file, tablespace, and database. Unless it is 
required that all transactions use the same lock granularity, j 
the DBMS must be able to coordinate concurrent transac- 
tions that request locks at different levels in the resource 
hierarchy. The typical solution is once a transaction requests 
locks at some resource level, it will not request additional 
locks on lower levels of the same resource (because other : 
concurrent transactions may acquire other locks on portions 
of that resource that are compatible with the first lock put on 
the resource), but it may request locks at higher levels. It is 
possible for a single transaction to use different lock granu- 
larities for different statements, but this is not significant for ; 
the discussion at hand. 

The following intent locks are needed: intent to request 
read (UR) locks indicate an intent to request read locks at 
some lower level, intent to request write (IW) locks indicate 
an intent to request write locks at some lower level, and : 
RIW, which provides read access to the entire resource in 
question (e.g., a table) while also enabling the transaction to 
request update and write locks at some lower level (such as 
at the page or tuple level). It should be noted that an IW lock 
on a table enables its holder to request R. U and W locks (not 
just W locks) on tuples or pages with the table. An IW lock 
on a resource will be promoted to an RIW lock if the 
transaction holding the IW lock requests an R lock on the 
same resource. 

Two transactions with overlapping IW locks are consid- 
ered to be compatible because the potential conflicts will be 
resolved at some lower level in the resource hierarchy. For 
example, two transactions may need to update various tuples 
in a relational table. The both acquire IW locks on that table 
(and probably also on some higher level resources, such as 
file or tablespace, as well as the database), and then R, U or 
W locks on individual tuples. As long as the two transactions 
do not access the same tuple, then there will no conflict. 
Should they happen to access the same tuple, then there will 
be a conflict, and the possibility of deadlock cannot be 
completely excluded. However, the potential deadlocks 
caused by overlapping IW requests are, in general, no worse 
than the potential deadlocks associated with other resource 
locking situations. 

The complete lock (access mode) compatibility matrix is 
shown in Table 3. 

TABLE 3 

Compatibility M atrix for Access Modes 



B 



IR 



U 



IW 



RIW 



B 
IR 
R 
U 

rw 

RTW 

w 

X 



Note that the RIW row/column is identical to the inter- 
section of the R and IW rows/columns. In practice, browse 
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(B) locks and exclusive (X) locks are not used at the lowest 
resource levels. Using B locks at the lowest levels would, at 
least partially, defeat the purpose of using isolation level UR 
in the first place. For example, in a relational DBMS a 
transaction using the UR isolation level may request a 
browse lock at the table level (and all levels above the table 
level), and then proceed without requesting any locks on 
pages or tuples. Alternately, the transaction may request 
some sort of low-cost, short duration locks (known as 
latches) on pages or tuples to ensure atomicity of individual 
read operations. 

Conditional Conflict Serializability 

The present invention is based on the premise that seri- 
alizability is an unsuitable correctness criterion for some 
types of applications, such as concurrent engineering, typi- 
fied by CAD and CASE applications. The present invention 
uses a new correctness criterion, herein called conditional 
conflict serializability (CCSR) which is a weaker kind of 
serializability based on a weaker notion of conflict between 
transactions. 

The idea behind CCSR is to depart from a purely com- 
mutativity based definition of conflict. While write opera- 
tions are still considered to be mutually conflicting, write- 
' read and read-write conflicts are made conditional. This is 
achieved by using "parameterized" read and write modes, 
and corresponding parameterized read and write locks. 

If R(A) and W(B) denote parameterized read and write 
modes, respectively, where A and B denote subsets of some 

* parameter domain D, R(A) and W(B) are compatible if and 
only if B is a subset of A: B_cA. For example, if the 
parameter domain D contains modes ul, u2, through u5, 
R(ul, u2) is compatible with W(ul) because ul_^_(ul, u2). 

- Recall that two transaction histories are "conflict equiva- 

* lent" if they contain the same transactions and operations, 
and conflicting operations of non-aborted transactions are 
ordered in the same way in both histories. Identical terms 
can be used to defined conditional conflict equivalence, so 

3 long as the parameter subset comparison is used to deter- 
mine which operations are conflicting. Thus, a transaction 
history is defined to be "conditional conflict serializable" if 
and only if it is conditional conflict equivalent to a serial 
transaction history. 

5 As discussed above, the serializability theorem states that 
a history H is serializable if and only if its serialization graph 
is acyclic. A generalized version of this theorem applies to 
CCSR. A conditional conflict serialization graph (CCSG) is 
defined in the same way as a regular serialization graph, 

o provided the term "conflicting operations" is understood to 
mean conditionally conflicting operations. Thus, a transac- 
tion history H is conditional conflict serializable (CCSR) if 
and only if the history's conditional conflict serialization 
graph (CCSG) is acyclic. 

5 The use of dirty reads does not provide a means for 
distinguishing between relatively stable database data and 
database data undergoing major changes. All sorts of incon- 
sistencies can result from dirty reads, and traditional 
DBMS's do not provide the user with any hints as to what 

K) they might be. On the other hand, the parameterized access 
modes of the present invention make it possible for database 
users (i.e., typically, application programs) to receive infor- 
mation about the reliability of uncommitted data from the 
parameters the writer of the data has attached to the write 

>5 lock on the data. More generally, the parameterized access 
modes of the present invention (A) enables application 
programmers to customize the notion of conflict between 
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transactions, and (B) enables applications to communicate to 
each other the quality of uncommitted data. 

The parameter domain D can be user defined, or defined 
differently in different database systems. The "data model" 
used can be simple or complex, and thus the number of 
parameters in domain D can be small or large, depending on 
the needs of the application programs. 

Using the present invention, the standard assumption that 
read and write modes are mutually incompatible is reduced 
to a default, which transactions can override by proper use 
of parameters. Instead, applications or transactions can 
specify when reading and writing is incompatible. Using the 
example discussed above in which the parameter domain D 
contains modes ul, u2, through u5: 
R(ul, u2) and W(ul) are compatible, 
R(ul) and W(ul) are compatible, 
R(ul) and W(u2) are not compatible, and 
R(u2) and W(u2, u3) are not compatible. 
Non-parameterized read and write modes can still be 
denoted as R and W, but can be thought of as R(0) and W(*), 
where 0 denotes the empty set and * denotes an arbitrary 
superset of D. Thus, according to the rule that R(A) and 
W(B) are compatible if and only if B_c^A, R(0) is incom- 
patible with all write modes and W(*) is incompatible with 
all read modes. Generally, there will be no such thing as a 
write mode that is compatible with every read mode, but 
R(D) denotes the read mode that is compatible with every 
write mode W(B) except W. 

When an application uses a parameterized write mode, it 
is indicating a willingness to share information with readers. 
That is, a transaction using parameterized writes indicates to 
other transactions the degree of safety associated with 
reading data that it has not yet committed. Analogously, the 
use of parameterized read modes by a transaction indicates 
willingness to read data that belongs to parameterized writ- 
ers. The new access mode compatibility matrix, using 
parameterized access modes, is shown in Table 4. In Table 
4, * indicates unconditional compatibility, blank table 
entries indicate unconditional incompatibility, and formulas 
such as B2cM and Bl <= A2 indicate conditional compat- 
ibility. 
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reliability categories. Each such category is represented by 
a reliability classification indicator, that is by a parameter in 
domain D. 

Especially for long lived transactions, it may be necessary 
5 to allow transactions to update the parameters associated 
with their write locks over time. For instance, the write 
locked data may initially be very unreliable (denoted by 
parameter ul), and then may be progressively upgraded to 
higher and higher levels of reliability (denoted by 
parameters, u2, u3, and so on) as the transaction progresses. 
10 Further, in systems having long lived transactions, there 
may be a need for lock management methods that do not 
simply block a transaction when incompatible lock modes 
are encountered. Rather, in at least some situations, param- 
eterized read modes may be treated as a request for data 
15 filtering, such that objects that are locked in incompatible 
write modes are skipped by parameterized reads. In some 
implementations of the present invention, applications using 
parameterized read access requests may include an addi- 
tional filter/wait flag to indicate if the read request is to be 
20 serviced by filtering out objects locked in incompatible write 
modes or is to wait for them to become available. 

The "uncommitted dependency problem," the "dirty read" 
problem and the "temporary update problem" are three 
names for the same thing: the use of uncommitted data is 
25 unreliable because it is subject to further change, due either 
to transaction abort or further modification by the applica- 
tion. The real problem is that an application can retrieve 
uncommitted data "assuming" that it is reliable, and then go 
ahead and do something based on this assumption. Contrary 
30 to this, the parameterized access mode method of the present 
invention explicitly informs applications when uncommitted 
data is encountered and also delivers information about the 
reliability of the uncommitted data. The application is free to 
handle such a situation in whatever way it sees fit: it may 
35 continuing as if nothing special happened, it may invoke 
some special procedure, it may perform a full or partial 
rollback, or do something else. Since no application will be 
deceived into believing that uncommitted data can be fully 
trusted, the uncommitted dependency problem is eliminated 
40 when using the present invention. 

The incorrect summary problem and the inconsistent 
analysis problem are two versions of another problem: an 
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Parameterized lock modes increase the amount of memory 
used by the lock manager to record each lock, and also 
increase the amount of computation required to resolve lock 
requests. 

It may be noted that the present invention does not force 
users (i.e., applications) to quantify uncertainty, but rather 
allows them to classify it. That is, users can denote unreli- 
able data as belonging to one or more of a predefined set of 



application may retrieve multiple data items and use them as 
input to some calculation, such as finding a sum or average, 
but interference from a concurrent transaction may cause the 
calculated value to be incorrect. This problem occurs when 
an updating application involves at least two data items: one 
that has already been retrieved by the analyzing application 
and one that has not yet been retrieved. One possible 
solution to this problem is to use an unparameterized read, 
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65 
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which is incompatible with all write modes. However, this 
solution is undesirable or impossible in some situations. 

Another possible solution, applicable only to special 
cases, is to establish a rule that all updates involving more 
than one data item should be performed using write mode 5 
parameters from a subset S of D. Any reader than needs to 
perform a consistent data analysis needs to avoid reading 
data that is write locked by any other transaction using a 
write mode parameter in subset S. 

Another possible solution related to access mode usage is 10 
to label data modification as minor, medium and major (or 
any other set of gradations). Thus a user would have objects 
locked in W(minor) mode most of the time, but would 
upgrade to W(medium) or W(major) whenever more sig- 
nificant changes than usual are to be performed, such as 15 
shuffling the sequence of data items, deleting and inserting 
multiple data items, and so on. After the major changes have 
been made, the user would downgrade the write locks to 
W(minor). In this way, readers can protect themselves from 
reading data in the midst of undergoing major changes, 20 
while accepting smaller levels of data inconsistency. 

Handling Resource Access Requests 
Referring to FIG. 4, it can be assumed that in any system 
utilizing the present invention, a subset of the transactions 2 5 
access database objects using parameterized read and 
parameterized write access modes, while other transactions 
used unparameterized access requests. Each transaction 
using a parameterized write mode of access for a database 
object specifies a write access mode, and a write access 30 
mode parameter, where the write access mode parameter 
indicates a reliability classification to other transactions that 
may request read access to the database object. Each trans- 
action using a parameterized read mode of access for a 
database object specifies a read access mode, and a read 35 
access mode parameter, where the read access mode param- 
eter indicates one or more reliability classifications that are 
acceptable to the transaction. Whenever a transaction 
requests access to a specified database object, the DBMS 
generates a corresponding lock request for the object (step 40 
220). If the access request is a parameterized conditional 
access request, a corresponding parameterized lock request 
is generated. 

The system's lock manager processes each lock request 
by searching the lock table (steps 222, 224) for any corre- 45 
spending previously generated locks. Next, it checks to see 
if any previously granted lock is conflicting or potentially 
conflicting with the requested lock (steps 226, 230, 232). 
Two lock requests are unconditionally conflicting if their 
resource ranges overlap and the access modes of the two so 
requests are incompatible (step 226). For example, the blank 
positions in Table 4 represent unconditionally conflicting 
access requests. In terms of the data structures shown in 
FIGS. 2 and 3, the access mode of the current request is 
compared with the most restrictive access mode previously 55 
granted for each of the overlapping resources for which any 
locks have been granted. For example, if the current access 
request is for an upgrade (U) mode or a write (W) mode, and 
there is already a granted lock for an overlapping resource 
that has a U or W mode, the current access request is 60 
unconditionally conflicting with the previously granted lock. 
If the lock request being processed is unconditionally con- 
flicting with any outstanding, previously granted lock (step 
226), the lock request is put on a queue of pending requests 
(step 228). 65 

Two requests are conditionally conflicting if analysis of 
their read/write parameters is necessary to determine 
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whether a conflict exists (step 230). Using the access modes 
described above, the read/write parameter comparison per- 
formed for each pair of potentially conflicting requests are 
those shown in Table 4 (step 232). That is, the conditional 
conflict is resolved by determining whether the write param- 
eters for the write lock in question are a subset of the read 
parameters for the read lock in question. If so, then there is 
no conflict. If not, then the requested lock is in conflict with 
the outstanding previously granted lock. If none of the 
outstanding, previously granted locks is in conflict with the 
requested lock, the requested lock is granted (step 234). 
Otherwise it is put on a queue of pending lock requests (step 
228). Every time a previously granted lock is released, any 
pending lock requests that overlap with the resource asso- 
ciated with the released lock are reevaluated (step 238). 

Alternate Embodiments 

The present invention may be implemented in DBMS's, 
transaction processing monitors, persistent programming 
languages, and concurrency control services for object 
resource brokerage systems. It may be distributed either in 
the form of such systems, or as a computer program product 
that is distributed on computer readable media such as 
magnetic data storage media (i.e., disks or tapes), CDROM, 
or the like. A computer program product embodiment of the 
present invention may be distributed electronically, over the 
Internet or other communications network, as a computer 
data signal embodied in a carrier wave. 

While the present invention has been described with 
reference to a few specific embodiments, the description is 
illustrative of the invention and is not to be construed as 
limiting the invention. Various modifications may occur to 
those skilled in the art without departing from the true spirit 
and scope of the invention as defined by the appended 
claims. 

What is claimed is: 
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1 . A resource lock management 
system, comprising: 

a lock data structure system which 
stores [storing] lock data representing 
granted and pending resource lock requests, 
wherein the data representing each granted 
and pending resource lock request includes: 
data indicating a resource to which access 
has been granted or requested, and an 
access mode associated with the resource 
lock request; 

wherein a subset of the granted and 
pending resource lock requests are 
parameterized resource lock requests and 
the data representing each resource lock 
request in the subset further includes one or 
more parameter values indicating a data 
reliability classification associated with the 
resource lock request; and 

a lock manager for evaluating, 
granting and denying resource lock 
requests, including determining when a 
resource lock request is unconditionally 
conflicting with any granted resource lock 
request, determining when the resource 
lock request is conditionally conflicting 
with any granted resource lock request, and 
evaluating the resource lock request with 
respect to each conditionally conflicting 
granted resource lock request by 
performing a predefined comparison of the 
parameter values for the resource lock 
request with the parameter values for each 
conditionally conflicting granted resource 
lock request* 

wherein the lock data structure 
system includes: 

a first data structure w hich stores 
information of a pending or granted lock 
request, the first data structure including: 

a field which stores an 
access mode of a resource; 

a field which stores an 
identification of a transaction associated 
with the first data structure; and 

a field which stores 
parameters of a data reliability 
classification associated with a pending or 
granted resource lo ck request; 
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a second data structure which 

stores inf ormation of a lock, the second 
data structure including: 

a field which stores an 
identification of a lockable resource which 
corresponds to said data indicating a 
resource to which access has been granted 
or reques ted; and 

a field which references the 
first data structure. 

2. The resource lock management 
system of claim 1, wherein the resource 
lock request is conditionally conflicting 
with a granted resource lock request only 
when (A) both the resource lock request 
and the granted resource lock request are 
parameterized resource lock requests and 
(B) the resource lock request is neither 
unconditionally conflicting nor 
unconditionally compatible with the 
granted resource lock request. 

3. The resource lock management 
system of claim 2, wherein when resource 
lock request is a parameterized read lock 
request R(A), where A represents the 
parameter values for the parameterized 
read lock request, and the granted resource 
lock request is a parameterized write lock 
request W(B), where B represents the 
parameter values for the parameterized 
write lock request, the lock manager 
determines whether the resource lock 
request is conflicting with the granted 
resource lock request by determining 
whether or not B is a subset of A. 

4. A resource lock management 
method, comprising the steps of: 

storing, in a data struc ture system, 
lock data representing granted and pending 
resource lock requests, wherein the data 
representing each granted and pending 
resource lock request includes: data 
indicating a resource to which access has 
been granted or requested, and an access 
mode associated with the resource lock 
request; 

wherein a subset of the granted and 
pending resource lock requests are 
parameterized resource lock requests and 
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the data representing each resource lock 
request in the subset further includes one or 
more parameter values indicating a data 
reliability classification associated with the 
resource lock request; and 

evaluating, granting and denying 
resource lock requests, including 
determining when a resource lock request is 
unconditionally conflicting with any 
granted resource lock request, determining 
when the resource lock request is 
conditionally conflicting with any granted 
resource lock request, and evaluating the 
resource lock request with respect to each 
conditionally conflicting granted resource 
by performing a predefined comparison of 
the parameter values for the resource lock 
request with the parameter values for each 
conditionally conflicting granted resource 
lock request* 

wherein the lock data structure 
system includes; 

a first data structure w hich stores 
information of pending or granted lock 
request, the first data structure including; 

a field which stores an 

access mode of a resource; 

a field which stores an 
identification of a transaction associated 
with the first data structure; and 

a field which stores 
parameters of a data reliability 
classification associated with a pending or 
granted resource lock request; 

a second data structure which stores 
information of a lock, the second data 

structure including; 

a field which stores an 
identification of a lockahle resource which 

corresponds to said data indicating a 

resource to which access has been g ranted 
or requested; and 

a field which references the 
first data structure . 

5. The resource lock management 
method of claim 4, wherein the resource 
lock request is conditionally conflicting 
with a granted resource lock request only 
when (A) both the resource lock request 
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and the granted resource lock request are 
parameterized resource lock requests and 
(B) the resource lock request is neither 
unconditionally conflicting nor 
unconditionally compatible with the 
granted resource lock request. 

6. The resource lock management 
method of claim 5, wherein when resource 
lock request is a parameterized read lock 
request R(A), where A represents the 
parameter values for the parameterized 
read lock request, and the granted resource 
lock request is a parameterized write lock 
request W(B), where B represents the 
parameter values for the parameterized 
write lock request, the resource lock 
request is evaluated with respect to the 
granted resource lock request by 
determining whether or not B is a subset of 
A. 

7. A computer program product for 
use in conjunction with a computer 
system, the computer program product 
comprising a computer readable storage 
medium and a computer program 
mechanism embedded therein, the 
computer program mechanism comprising; 

instructions for storin g, in a data 
structure system, lock data representing 
granted and pending resource lock 
requests, wherein the data representing 
each granted and pending resource lock 
request includes: data indicating a resource 
to which access has been granted or 
requested, and an access mode associated 
with the resource lock request; 

wherein a subset of the granted and 
pending resource lock requests are 
parameterized resource lock requests and 
the data representing each resource lock 
request in the subset further includes one 
or more parameter values indicating a 
classification associated with the resource 
lock request; and 

lock manager means for evaluating, 
granting and denying resource lock 
requests, including determining when a 
resource lock request is unconditionally 
conflicting with any granted resource lock 
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request, determining when the resource 
lock request is conditionally conflicting 
with any granted resource lock request, and 
evaluating the resource lock request with 
respect to each conditionally conflicting 
granted resource lock request by 
performing a predefined comparison of the 
parameter values for the resource lock 
request with the parameter values for each 
conditionally conflicting granted resource 
lock request, 

wherein the lock data structure 
system includes; 

a first data s tructure which stores 
information of a pending or granted lock 
request, the first data structure including: 
a field which stores an 

access mode of a resource; 

a field which stores an 
identification of a transaction a ssociated 
with the first data structure; and 

a field which stores 
parameters of a data reliability 
classification associated with a pending or 
granted resource lo ck request; 

a second data structure which stores 
information of a loc k, the second data 
structure including: 

a field which stores an 
identification of a lockable res ource which 
corresponds to said data indicating a 
resource to which access has been granted 
or requested; and 

a field which r eferences the 
first data structure. 

8. The computer program product 
of claim 7, wherein the resource lock 
request is conditionally conflicting with a 
granted resource lock request only when 

(A) both the resource lock request and the 
granted resource lock request are 
parameterized resource lock requests and 

(B) the resource lock request is neither 
unconditionally conflicting nor 
unconditionally compatible with the 
granted resource lock request. 

9. The [resource lock management 
system] computer program product of claim 
8, wherein when resource lock request is a 
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parameterized read lock request R(A), 
where A represents the parameter values 
for the parameterized read lock request, 
and the granted resource lock request is a 
parameterized write lock request W(B), 
where B represents the parameter values 
for the parameterized write lock request, 
the lock manager determines whether the 
resource lock request is conflicting with 
the granted resource lock request by 
determining whether or not B is a subset of 
A. 

10. A resource lock management 
system according to claim 1 , wherein the 
lock data structure system further includes 

a third data structure, the third data 
structure including; 

a field which references the 

second data structure, 

1 1 . A resource management 
system according to claim 10, wherein: 

the second data structure further 
includes: 

a field which stores aggregated 
read parameters of first data structures 
reference d by the second data structure; 
and 

a field which stores aggregated 
write parameters of first data s tructures 
referenced by the s econd data structure, 

wherein the aggregated read and 
write parameters co rrespond to said one or 
more parameter values indicating a data 
reliability classification associated with the 
resource lock request. 

12. A resource management 
system according to claim 1 1, wherein the 
second data structure further includes: 

a field which stores an 
identifica tion of a most restrictive access 
mode of the lockable resource and which 
corresponds to said access mode associated 
with the resource lo ck request. 

13. A resource lock management 
method according to claim 4, wherein the 
lock data structure system furt her includes 
a third data structure, the third data 
structure including: 

a field which references the 
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second da ta structure. 

1 4. A resource lock management 
method according to claim 13, wherein: 

the second data structure further 
includes: 

a field which stores aggregated read 
parameters of first data structures 
referenced hy the second data structure; and 

a field which stores aggregated 
write parameters of first data structures 
referenced hy the second data structure, 

wherein the aggregated read and 
write parameters correspond to said one or 
more parameter values indicating a data 
reliability classification associated with the 
resource lock request. 

15. A resource lock management 
method according to claim 14, wherein the 
second data structure further includes: 

a field which stores an identification 
of a most restrictive access mode of the 
lockable resource and which corresponds to 
said access mode associated with the 
resource l ock request. 

16. A computer program product 
according to claim 7, wherein the lock data 
structure system further includes a third 
data structure, the third data structure 
including; 

a field which references the 
second data structure. 

17. A computer program product 
according to claim 1 6, wherein: 

the second data structure further 

includes; 

a field which stores aggregated read 
parameters of first data structures 
referenced hy the second data structure; and 

a field which stores aggregated 
write parameters of first data st ructures 
referenced hy the second data structure, 

wherein the aggregated read and 
write par ameters correspond to said one or 
more parameter values indicating a data 
reliability classification associated with the 
resource lock request. 

18. A computer program product 
accordin g to claim 1 7, wherein the second 
data structure furthe r includes: 
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a field which stores an 
identification of a most restrictive access 
mode of the lockable resource and which 
corresponds to said access mode associated 
with the resource lock request. 

19. A resource lock management 
system, comprising; 

a lock data structure system which 
stores lock data representing granted and 
pending resource lock requests, wherein 
the data r epresenting each granted and 
pending resource lock request includes: 
data indicating a resource to which access 
has been granted or requested, and an 
access mode associated with the resource 

lock request; 

wherein a subset of the granted and 
pending resource lock requests are 
parameterized resource lock requests and 
the data representing each resource lock 
request in the subse t further includes one 
or more parameter values indicating a data 

reliability classification associated with the 
resource lock request; and 

a lock manager for evaluating, 
granting and denying resource lock 
requests, including determining when a 
resource lock reques t is unconditionally 
conflicting with any granted resource lock 
request, determining when the resource 
lock request is conditionally conflicting 
with any granted resource lock request, 
and evaluating the resource lock request 
with respect to each conditionally 
conflicting granted resource lock request 
by performing a predefined comparison of 
the parameter values for the resource lock 
request with the parameter va lues for each 
conditionally conflicting granted resource 
lock request, 

wherein the lock data structure 
system includes; 

a first data structure which stores 
information of a loc k, as well as the 
pending and granted requests thereof, the 
first data structure including: 

a field which stores an 
identification of a lockable re source which 
corresponds to said data indicating a 
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resource to which access has been granted 
or requested; and; 

a field which stores an 
access mode of a resource which 
corresponds to said access mode associated 
with the resource lock request; 

a field which stores 
parameters of a dat a reliability 
classification associated with a resource 
loclc requ est which corresponds to said one 
or more parameter values indicating a data 

reliability classification associated with the 
resource lock request; 

a second data structure including: 
a field which references the 
first data structure. 

20. A system according to claim 
19 f wherein the field which stores an access 
mode stores a most restrictive access mode 
of the granted lock requests, 

21. A system according to claim 
19 T wherein the field which stores 
parameters comprises: 

a field whic h stores read 
parameters; and 

a field which stores write 
parameters. 

22. A system according to 21 , 
wherein: 

the read parameters are aggregated 
read parameters of granted read requests; 
and 

a write parameters are aggregated 
write parameters of granted write requests. 

23. The resource lock management 
system of claim 1 9 T wherein the resource 
lock request is conditionally conflicting 
with a granted resource lock request only 
when (A) both the resource lock request 
and the granted resource lock r equest are 
parameterized resource lock requests and 
(B) the resource lock request is neither 
unconditionally conflicting nor 
unconditionally compatible with the 
granted resource lo ck request. 

24. The resource lock management 
system of claim 23. wherein when resource 
lock request is a parameterized read lock 
request Rf A) r where A represents the 
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parameter values for the param eterized 
read lock request, a nd the granted resource 
lock request is a parameterized write lock 
request W(B) T where B represents the 
parameter values for the parameterized 
write lock request, the lock manager 
determines whether the resource lock 
request is conflicting with the granted 
resource lock request by determining 
whether or not B is a subset of A. 

25. A reso urce lock management 
method, comprising the steps of; 

storing, in a data structure system, 
lock data representing granted and pending 
resource lock requests, wherein the data 
representing each granted and pending 
resource lock request includes: data 
indicating a resource to which access has 
been granted or req uested, and an access 
mode associated with the resource lock 
request; 

wherein a subset of the granted and 
pending resource lock requests are 
parameterized resource lock requests and 
the data representing each reso urce lock 
request in the subset further includes one 
or more parameter values indicating a data 
reliabilit y classification associated with the 
resource lock request; and 

evaluating, granting a nd denying 
resource lock requests, including 
determining when a resource lock request 
is unconditionally conflicting with any 
granted resource lock request, determining 
when the resource lock request is 
conditionally conflicting with any granted 
resource lock request, and evaluating the 
resource lock request with res pect to each 
conditionally conflicting granted resource 
by performing a predefined comparison of 
the parameter values for the re source lock 
request with the parameter values for each 
conditionally conflicting granted resource 
lock request, 

wherein the lock data structure 
system includes: 

a first data structure which stores 
information of a lock T as well as the 
pending and granted requests thereof, the 
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first data structure including; 

a field which stores an 
identification of a lockahle resource which 
corresponds to said data indicating a 
resource to which a ccess has been granted 

or requested; and; 

a field which stores an 
access m ode of a resource which 
corresponds to said access mode associated 
with the resource lock request; 

a field which stores 
parameters of a data reliability 
classifica tion associated with a resource 
lock request which corresponds to said one 
or more parameter values indicating a data 
reliability classification associ ated with the 
resource lock request; 

a second data structure including: 

a field which r eferences the 
first data structure. 

26. A method according to claim 
25 r wherein the field which stores an access 
mode stores a most restrictive access mode 
of the granted lock requests. 

27. A method according to claim 
25 r wherein the field which stores 
parameters comprises: 

a field which stores read 
parameters; and 

a field which stores write 
parameters, 

28. A method according to 27, 
wherein; 

the read parameters are aggregated 
read parameters of granted read requests; 
and 

a write parameters are aggregated 
write parameters of granted wri te requests. 

29. A method according to claim 
25, wherein the res ource lock request is 
conditionally confli cting with a granted 
resource lock request only when (A) both 
the resource lock re quest and the granted 
resource lock request are parameterized 
resource lock requests and (B) the resource 
lock request is neither unconditionally 
conflicting nor unconditionally compatible 
with the granted resource lock request 

30. A method accordin g to claim 



29 f wherein when resource lock request is 
a parameterized read lock request R(A), 
where A represents the parameter values 
for the parameterized read lock request, 
and the granted res ource lock request is a 
parameterized write lock request W(B), 
where B represents the parameter values 
for the parameterize d write lock request, 
the resource lock request is evaluated with 
respect to the granted resource lock request 

by determining wh ether or not B is a 
subset of A. 

3 1 . A computer program product 
for use in conjuncti on with a computer 
system, the computer program product 
comprising a computer readable storage 
medium and a computer program 
mechanism embedded therein, the 
computer program mechanism comprising: 

instructions for storing, in a data 
structure system, lock data representing 
granted and pendin g resource lock 
requests, wherein the data representing 
each granted and pending resource lock 
request includes: data indicating a resource 
to which access has been granted or 
requested, and an access mode associated 
with the resource lock request; 

wherein a subset of the granted and 
pending resource lock requests are 
parameterized reso urce lock requests and 
the data representing each resource lock 
request in the subset further in cludes one 
or more parameter values indicating a 
classification associated with the resource 
lock request; and 

lock manager means for evaluating, 
granting and denying resource lock 

requests, including determining when a 

resource lock request is unconditionally 
conflicting with an y granted resource lock 
request, determining when the resource 
lock request is conditionally conflicting 
with any granted resource lock request, 
and evaluating the resource lock request 
with resp ect to each conditionally 
conflicting granted resource lock req uest 
by performing a predefined co mparison of 
the parameter values for the resource lock 
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request with the parameter values for each 
conditionally conflicting granted resource 
lock request, 

wherein the lock data structure 

system includes: 

a first data structure which stores 
information of a 1ock T as well as the 
pending and granted requests thereof, the 
first data structure including; 

a field which s tores an 
identification of a lockahle resource which 
correspon ds to said data indicating a 
resource to which access has been granted 
or requested; and; 

a field which stores an 
access mode of a resource which 
corresponds to said access mode associated 
with the resource lock request; 

a field which stores 
parameters of a data reliability 
classification associated with a resource 
lock request which corresponds to said one 
or more parameter values indic ating a data 
reliability classification associated with the 
resource lock request; 

a second d ata structure including: 

a field which references the 
first data structure. 

32. A computer program product 
according to claim 31 , wherein the field 
which stores an acc ess mode stores a most 
restrictive access mode of the granted lock 
requests. 

33. A computer program product 
according to claim 31, wherein the field 
which st ores parameters comprises: 

a field which stores read 
parameters; and 

a field which stores write 
parameters. 

34. A computer progr am product 
according to 33, wherein: 

the read parameters are aggregated 
read parameters of granted read requests; 
and 

a write parameters are ag gregated 
write parameters of granted write requests 

35. The computer program product 
of claim 31 , wherein the resource lock 
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request is conditionally conflicting with a 
granted resource lock request only when 

(A) both the resource lock request and the 
granted resource lock request are 
parameterized resource lock re quests and 

(B) the resource lock request is neither 
unconditi onally conflicting nor 
unconditionally co mpatible with the 
granted resource lock request. 

36. The computer pro gram product 
of claim 31 T wherein when resource lock 
request is a parameterized read lock 
request R(A), where A represents the 
parameter values for the parameterized 
read lock request, and the granted resource 
lock request is a parameterized write lock 
request W(B), where B represents the 
parameter values fo r the parameterized 
write lock request, the lock manager 
determines whether the resource lock 
request is conflictin g with the granted 
resource lock request by determining 
whether or not B is a subset of A. 

37. A resource lock management 
system, comprising: 

a memory which store s a first data 
structure which stores information of a 
pending or granted lock reques t, the first 
data structure including: 

a field which stores an 

access mode of a resource; 

a field which s tores an 
identification of a transaction associated 
with the first data st ructure; and 

a field which stores 
parameters of a data reliability 
classification associated with a pending or 
granted resource lock request; 

a memory which store s a second 
data structure which stores information of 
a lock P the second data structure including: 

a field which stores an 
identification of a lockahle resource; and 

a field which r eferences the 
first data structure; 

a memory which stores a third data 
structure, the third data struct ure including: 

a field which references the 
second data structure. 



31 

38. A resource management system 
according to claim 37, wherein: 

the second data structure further 
includes; 

a field which stores aggregated read 
parameters of first data structures 
referenced by the second data structure; and 

a field which stores aggregated 
write parameters of first data structures 
referenced by the second data structure. 

39. A resource management system 
according to claim 38, wherein the second 
data structure further includes: 

a field which stores an identification 
of a most restrictive access mode of the 
lockable resource. 

40. A resource management system 
according to claim 37, wherein the second 
data structure further includes: 

a field which stores an identification 
of a most restrictive access mode of the 
lockable resource. 

41 . A resource lock management 

system, comprising: 

a memory which stores a first data 
structure which stores information of a 
lock, as well as the pending an d granted 
requests thereof, the first data structure 
including; 

a field which stores an 
identification of a lockable resource; 

a field which stores an 

access mode of a resource; 

a field which stores 
parameters of a data reliability 
classification associ ated with a resource 
lock request; 

a memory which stores a second 
data structure, the se cond data structure 
including : 

a field which references the 
first data structure.granted reso urce lock 
request; 

a memory which stores a second 
data structure which stores information of a 
lock, the second data structur e including: 

a field which stores an 
identification of a lockable resource; and 

a field which references tbe 
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first data structure; 

a memory which stores a third data 
structure, the third data structure including : 
a field which r eferences tbe 
second data structure. 

38. A resource management 
system according to claim 37, wherein: 

the second data structure further 
includes: 

a field which stores aggregated 

read parameters of first data structures 
referenced by the second data structure; 
and 

a field which stores aggregated 
write parameters of first data structures 
referenced by the second data structure. 

39. A resource management 
system according to claim 38, wherein the 
second data structu re further includes: 

a field which stores an 
identification of a most restrictive access 
mode of the lockabl e resource. 

40. A resource management 
system according to claim 37, wherein the 
second data structu re further includes: 

a field which stores an 
identification of a most restrictive access 
mode of the lockabl e resource. 

41 . A resource lock management 
system, comprising; 

a memory which stores a first data 
structure which stores information of a 
lock, as well as the pending and granted 
requests thereof, the first data structure 
including: 

a field which stores an 
identification of a lockable resource; 

a field which stores an 
access mode of a resource; 

a field which stores 
parameters of a data reliability 
classification associated with a resource 
lock request; 

a memory which stores a second 
data structure, the second dat a structure 
including; 

a field which r eferences the 
first data structure 

42. A system accordi ng to claim 
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41, wherein the field which stores an access 
mode stores a most restrictive access mode 
of the granted lock requests. 

43, A system according to claim 

42, wherein the fiel d which stores 
parameters comprises: 

a field which stores read 
parameters; and 

a field which stores write 
parameters. 

44. A system according to 43, 
wherein: 

the read par ameters are aggregated 
read parameters of granted read requests; 
and 

a write para meters are aggregated 
write parameters of granted write requests. 



